Some Internet web servers often provide web pages that are personalized for each particular user based on the user's identity and state information maintained at the server for that user. For example, in electronic bill presentment technology, when a user is properly authenticated, a web page is provided to the user displaying the state of that user's current financial bills. The user may pay the bills electronically, whereby the server adjusts the state information to reflect which bill has been paid, how much has been paid, and so on.
At the same time, many users of such custom-generated web pages run software programs on their local machine that deal with related information. For example, a user may track personal financial information, including the state of the user's bills, in an application program such as Microsoft® Corporation's Money99 program.
However, there has heretofore not been a straightforward way to synchronize the state information maintained at the server with the data maintained by the client application program. For example, when a user pays a bill on an electronic bill presentment server, the information is not synchronized with the user's financial data tracked by the application program. The user thus has to make a double entry, once to the server and once in the application program.
A number of solutions may be developed to perform the synchronization, however each these solutions have associated drawbacks. For one, the user could manually request synchronization by clicking on a synchronize button or the like displayed on the web page. However, as can be readily appreciated, not all users will understand this action nor will remember to do so, leading to inconsistencies that confuse and frustrate the user, i.e., many users would not find the link, realize what it did, and/or realize why the link should be clicked.
Another, more complex solution would be to develop a customized, “behind the scenes” mechanism for communicating with electronic bill presentment servers over an Internet connection. However, because of the complexity, it is not cost-efficient to do so, and moreover, would require substantial changes at both the client and server. Yet another solution would be to duplicate server functions at the client, and then have the client update the server. However, this would be performing the same work twice, which is undesirable, and also would lead to problems when the server functions needed to be changed. Moreover, the server has the actual state data, and thus the client would still have to synchronize before presenting information to the user. Lastly, the server could determine whether a client accessing it may have some data to synchronize by modifying browsers to inform the server when the browser is communicating on behalf of a client application. However, this is not a straightforward solution, nor is it backward compatible, as it would require modifying or replacing the large number of existing browsers.